Internetrecht door Arnoud Engelfriet

Dat zal tijd worden: de GNU Free Documentation License kan eindelijk worden afgedankt. Deze bijzonder onhandige licentie werd ooit door de Free Software Foundation ontwikkeld om “vrije softwaredocumentatie” onder uit te kunnen brengen. Het basisidee was hetzelfde als de GPL: iedereen mag de documentatie aanpassen, maar aangepaste documentatie mag je alleen verspreiden onder diezelfde GFDL.

Op zich een leuk idee, alleen viel de uitwerking nogal tegen. De FSF ziet documentatie en software als wezenlijk verschillend, en begon allerlei rare toevoegingen in de GFDL te stoppen. Zo kon je teksten opnemen die verplicht op de cover van een eventueel boek met de documentatie erin moesten verschijnen, en kon je aangeven dat bepaalde teksten altijd ongewijzigd overgenomen moesten worden. Wat de FSF dan weer kon gebruiken om haar GNU Manifesto aan allerlei handleidingen te hangen. Dat maakte de GFDL erg onhandig in de praktijk. Het Debian-project vond het zelfs zo onhandig dat men de GFDL tot “onvrije” licentie bombardeerde en alle GNU handleidingen uit haar Linux-distributie mikte.

Het Creative Commons-project kwam vervolgens met een set neutrale licenties. Helaas zat met name Wikipedia tegen die tijd al met een flinke berg teksten en afbeeldingen onder de GFDL, en als je eenmaal een licentie kiest, kom je er nauwelijks nog vanaf. Het probleem is namelijk dat Creative Commons en GFDL allebei bepalen dat gewijzigde versies onder dezelfde licentie uitgebracht moeten worden. Daardoor kan een GFDL tekst niet onder Creative Commons worden geplaatst of andersom.

In augustus vorig jaar kwam Creative Commons 3 uit. Deze licentie bevatte de ene helft van de oplossing: het is toegestaan om CC werk onder een “compatibele” licentie te plaatsen. Maar een licentie is pas compatibel als deze ook een bepaling bevat om het werk juist weer onder CC te zetten. En nu is het dan eindelijk zo ver: de nieuwste versie van de GFDL heeft zo’n bepaling gekregen.

De bepaling is wel specifiek voor Wikipedia en andere “Massive Multiauthor Collaboration Sites” geschreven. Het is enkel en alleen toegestaan om inhoud van MMC sites die voor 1 november 2008 online stond, om te zetten naar Creative Commons 3.0 ShareAlike. Oh ja, en alleen als de beheerder van die site de omzetting vóór 1 augustus 2009 uitvoert. Een tamelijk irritante constructie, die niet geheel in de spirit van wat Creative Commons nu eigenlijk wilde. Maar goed, het is al heel wat dat de FSF inziet dat haar licentie bijzonder onhandig was.

In theorie kan Wikipedia dus nu haar licentie omzetten naar GFDL 1.3 en vervolgens naar Creative Commons. De praktijk blijkt weerbarstig (zie hele berg discussie hierrr) want niet alle Wikipedianen zullen het daar mee eens zijn. Men heeft wel een deadline gekregen, zodat we mogen hopen dat die discussie niet al te lang meer zal duren.

Via Slashdot.

Update (15:57) Tonie is liev maar zijn er geen andere interessante meningen over GFDL? Bijvoorbeeld wat Wikimedia ervan vindt?

Arnoud
Afbeelding onder Free Art license.

Dat zal tijd worden: het Europees Octrooibureau (EPO) gaat een principiële uitspraak doen over wanneer je nu wel of niet octrooi op een software-gerelateerde uitvinding kunt krijgen. De Grote Kamer van Beroep van het EPO heeft onlangs een serie vragen van de President van datzelfde EPO voorgeschoteld gekregen over de reikwijdte van het verbod op octrooi op computerprogramma’s als zodanig”".

Over wat wel denigrerend softwarepatenten genoemd wordt, is veel te doen. Kan het, mag het, en zo ja onder welke voorwaarden. Het EPO nam begin jaren nul in uitspraak 1173/97 een beslissing waar ik nog elke keer weer hoofdpijn van krijg: een computerprogramma op zichzelf is geen computerprogramma als zodanig wanneer het een technisch computerprogramma op zichzelf is. Met “computerprogramma als zodanig” werd namelijk bedoeld een niet-technisch computerprogramma, zodat wel-technische computerprogramma’s geen computerprogramma’s als zodanig zijn. Wie heeft de Paracetamol?

In ieder geval, wat gaat het EPO nu proberen te verduidelijken?

Ten eerste: valt een computerprogramma alleen onder de uitzondering als het expliciet als “Computerprogramma” geclaimd wordt? In de octrooiclaims moet je namelijk precies aangeven waar je een octrooi op wilt hebben. Je kunt je uitvinding op verschillende manieren claimen, bijvoorbeeld als apparaat, als werkwijze of als stofje. Als het apparaat of de werkwijze software gebruikt, is het apparaat dan uitgesloten? Of alleen een claim op de software zonder het bijbehorende apparaat?

Vraag 2 gaat daarop door en wil weten of het uitmaakt of je in de claim erbij zet dat het computerprogramma op een fysieke drager staat. Dit omdat een aantal recente beslissingen bepaalt dat een uitvinding in beginsel octrooieerbaar is wanneer er technologie aan te pas komt, hoe oud die ook is.

In vraag 3 wordt gekeken naar wanneer je een computerprogramma als technologie kunt zien. Moet het criterium daarvoor zijn dat er een “technisch effect op een fysieke entiteit in de echte wereld” te meten is?

Vraag 4 begrijp ik niet helemaal. Die gaat over de activiteit van het programmeren zelf. Wanneer is daar sprake van technisch ontwikkelen, van werken aan techniek, van bouwen zeg maar. Waarom die vraag relevant is, snap ik niet. De manier van bouwen van een stoomtrein is toch ook niet relevant voor de vraag of je die stoomtrein kunt octrooieren?

In ieder geval, de antwoorden zullen erg belangrijk zijn voor de octrooipraktijk in Europa. Als de Grote Kamer een harde lijn inzet, kan dat dik de helft van alle Europese octrooien onderuit halen. Kiest men voor eenzelfde redenering als de (kleine) Kamer van Beroep in 2000 deed, dan zal de verkoop van Paracetamol flink toenemen, in ieder geval bij mij in Eindhoven.

Via Boek9.nl, dat de laatste tijd opvallend veel slashes in haar URLs heeft staan. Waarom hebben juridische informatiesystemen en CMS’en altijd zulke bizarre backends?

Arnoud

Creative Commons-licenties zijn een handige en eenvoudige manier om je eigen werk beschikbaar te stellen aan de internet-gemeenschap. Je kiest een van de zes mogelijke licenties, plakt de tekst op je werk en klaar ben je. Bij sites zoals Flickr zit het zelfs in de site ingebakken als je iets uploadt. Prachtig, maar er is één groot nadeel: hoe weet je dat die licentie wel klopt?

Er zijn allerlei redenen waarom een CC-licentie niet rechtsgeldig op een werk staat. Iemand uploadt andermans werk en zet daar een CC-licentie bij, bijvoorbeeld. Of een muzikant is bij Buma-Stemra aangesloten en gebruikt een CC-licentie die ook commercieel gebruik toestaat. Dat mag allemaal niet, maar het gebeurt. En hoe controleer je dat nu als afnemer van het werk? Je kent die auteur niet, dus je moet maar op zijn woord geloven dat hij de auteur is, en bevoegd is om die licentie te geven.

Contractjuristen lossen dit soort dingen op door in de licentieovereenkomst expliciet iets te vermelden à la “De licentiegever verklaart hierbij eigenaar van het werk te zijn en deze licentie te mogen geven”, het liefst gekoppeld aan een boetebeding. Blijkt nu dat de licentiegever helemaal geen eigenaar was, of een wurgcontract met iemand anders getekend te hebben waardoor hij deze licentie niet meer mag geven, dan heb je een mooie stok om je schade te verhalen als je door de werkelijke rechthebbende wordt aangesproken.

De Creative Commons-licenties hebben dit soort teksten nergens. Er wordt nergens gezegd dat de licentiegever maker is van het werk, maar alleen dat hij een licentie gaat geven. In de ‘legal code‘ wordt hij omschreven als de persoon “die het Werk volgens de voorwaarden van deze Licentie aanbiedt”. Dat kan dus betekenen: aanbieden als auteur, maar ook: aanbieden namens een ander. Of zelfs: aanbieden zonder dat te mogen.

Naar Nederlands recht zou je misschien nog wel kunnen betogen dat een licentiegever impliciet wel verklaart de rechten te hebben om de licentie te mogen geven. Maar dat gaat hier niet werken, want artikel 5 van de licentie voegt daar nog eens aan toe:

TENZIJ ANDERS SCHRIFTELIJK IS OVEREENGEKOMEN DOOR DE PARTIJEN, STELT DE LICENTIEGEVER HET WERK BESCHIKBAAR OP ‘AS-IS’ BASIS, ZONDER ENIGE GARANTIE, HETZIJ DIRECT, INDIRECT OF ANDERSZINS, MET BETREKKING TOT HET WERK, MET INBEGRIP VAN, MAAR NIET BEPERKT TOT GARANTIES MET BETREKKING TOT DE EIGENDOMSTITEL (…)

Oftewel: men weigert expliciet te beloven dat de licentiegever eigenaar is of zelfs maar gerechtigd is de licentie te geven. En dan wordt het lastig om alsnog te betogen dat je erop mocht vertrouwen dat het wel goed zat met die rechten.

Maak ik me nu druk om iets heel theoretisch of hebben we hier echt een wezenlijk probleem met CC te pakken?

Arnoud

“Bloggers hebben geen auteursrecht,” zo concludeerde Henk Blanken uit een artikel over het auteursrecht en internet van professor Bernt Hugenholtz, hoogleraar informatierecht aan de Universiteit van Amsterdam. Wie blogt, of een foto plaatst op Flickr, of een wetenschappelijk artikel plaatst op een universitaire website, wil zo graag gelezen worden dat hij stilzwijgend toestemming geeft voor hergebruik.

Henk’s mond viel er van open. De uwe ook? Het is een interessante vraag: wat mag je met andermans blog, comments of andere internetbijdragen? Auteursrecht geldt natuurlijk ook op internet, maar dat wil niet zeggen dat je niets mag doen met een werk tenzij de auteur dat expliciet heeft goedgekeurd.

Een licentie kan namelijk ook impliciet zijn. Wie een brief naar de krant stuurt, geeft een licentie om deze in de krant af te drukken (zelfs in gewijzigde vorm). Het archief van die krant gaat online, dus de brief ook. Ook daar moet je rekening mee houden, en ook daar geef je dus impliciet een licentie voor.

Hoe bepaal je dan wat er wel en niet onder zo’n impliciete licentie valt? Dat is erg lastig, omdat het afhangt van wat je erbij zette, wat de ontvangende partij bij het ontvangen had gezegd - en wat er geldt binnen de gemeenschap waar het werk wordt verspreid. Zo gelden onder modefotografen andere mores dan onder persfotografen als het gaat over hergebruik van foto’s. Net zo goed gelden er onder bloggers andere mores dan onder tijdschriftauteurs. En dat is wat Hugenholtz wilde aangeven toen hij de passage schreef waar Henk’s mond van open viel:

Voor zover deze auteurs geen gebruik maken van open content licenties, waarover hieronder meer, mag worden aangenomen dat er sprake is van een stilzwijgende toestemming (licentie) aan alle gebruikers van het internet. Voor deze categorie werken vormt het auteursrecht dus geen toegangsbelemmering.
Voor content die commercieel wordt aange­boden, ligt dat anders; hier gelden de regels van het auteursrecht ten volle.

Dit is volgens mij wat Henk zo oneerlijk vond. Als je blogt, is je werk vogelvrij, maar als je iets via een betaalsite aanbiedt, dan mogen anderen niets met je werk (behalve wat wettelijk is toegestaan, zoals citeren of een thuiskopie).

Maar draai het eens om: wat mag ik met een blog waar niets bij staat? Was het werkelijk de bedoeling van de auteur dat er, net als in een boek, helemaal niets met zijn blogteksten mag gebeuren? Dat wil er bij mij ook weer niet in. Je blogt om andere redenen dan de auteur van een boek. Je wilt, je verwacht dat anderen het lezen en elkaar erop wijzen. En daarvoor moeten ze die tekst kunnen doorgeven aan anderen. Als citaat, of integraal. Wat is daar erg aan voor een blogger?

Natuurlijk zijn er situaties die je als blogger niet had gewild. Zo was er in maart 2007 discussie over het boek Dagboekvaneenkindermeisje.com dat was gebaseerd op forumdiscussies bij Fok!. Hadden alle deelnemers aan die discussie bedoeld dat hun reacties tot boek werden verwerkt? Dat is echt een open vraag. (Een aantal gaf achteraf aan van niet, maar dat is wat laat.)

Maar let wel: dit zou alleen gelden als je blogt of publiceert op internet zonder aan te geven wat er wel en niet mag. Het kan dus slim zijn om duidelijk vast te leggen wat je wilt dat mensen doen door bijvoorbeeld een Creative Commons licentie te kiezen. Deze staat hergebruik toe, onder voorwaarden zoals “ongewijzigd” of “niet voor commerciële doeleinden”. Wie op die manier duidelijkheid schept over de licentie, heeft een goed verhaal tegen mensen die claimen een impliciete licentie te hebben gekregen.

Hebben jullie een licentie gekozen voor op je blog? En wat mag je doen met andermans blogtekst of foto’s als er niets bijstaat?

Arnoud

Omdat het hosten en verspreiden van tekst, audio en video normaal inbreuk op het auteursrecht is, moet je een website zoals Youtube of Flickr toestemming geven om je materiaal te verspreiden. Dit regelen deze sites meestal vooraf in de gebruiksvoorwaarden voor de site, zodat daar niet apart overhandeld kan worden. Die voorwaarden kunnen erg ver gaan.

In maart 2008 kwam Adobe in het nieuws over de voorwaarden voor haar online fotobewerkingsdienst ‘Photoshop Express’. Die bepaalden dat Adobe een onbeperkte en eeuwigdurende licentie kreeg om alles te doen met foto’s van gebruikers. Tot en met het verkopen van muismatten met de foto erop, bijvoorbeeld. Op zich mag dat, maar het was niet echt netjes om dat alleen in de kleine lettertjes aan te geven. Adobe heeft snel de voorwaarden ingeperkt tot die rechten die nodig waren om de dienst uit te kunnen voeren.

Sommige sites gaan nog verder: die eisen simpelweg het auteursrecht op. Dat kan niet zomaar. Voor overdracht van auteursrecht is een akte nodig, een ondertekend geschrift met handtekening van de maker. Hoewel ook een elektronische akte rechtsgeldig is, zijn algemene voorwaarden uit een gebruiksovereenkomst nog geen akte.

Vorig jaar september maakte ik me nog boos over de exclusieve licentie van MaakJeZo. De tekst uit hun licentie gaf hen als enige het recht om het werk van hun gebruikers te mogen gebruiken. Dat is een leuke truc om om die beperking over overdracht van auteursrecht heen te komen. Want zelfs de licentiegever, de maker dus, mag niets meer doen met het werk dat hij in exclusieve licentie aan een ander geeft. Maar netjes is het niet.

De voorwaarden van Hoedoe.nl (door ICTRecht geschreven) eist geen exclusieve licentie, maar wel iets anders:

7.5. Door akkoord te gaan met deze Algemene Voorwaarden machtigt Gebruiker Applinet om op te treden (waaronder het nemen van juridische stappen) tegen onrechtmatig gebruik van zijn Hoedoe(s) in andere media.

Deze constructie is erg handig voor Hoedoe, zeker wanneer een tekst door meerdere gebruikers is geschreven (denk aan Wikipedia). In dat geval is het niet altijd duidelijk wie kan optreden tegen schendingen van de licenties van de site. Door deze clausule is Applinet, het bedrijf achter Hoedoe, in staat om dat zelf te doen, zelfs als de gebruiker later onvindbaar blijkt.

Wie nog gekke dingen in die voorwaarden ziet, mag ze hieronder kwijt. De vinder van de raarste clausule of grootste fout krijgt 10% korting bij zijn eerstvolgende opdracht bij ICTRecht.

Arnoud

Mag je in de winkel gekochte software doorverkopen, zelfs als de EULA dat verbiedt? Deze al jaren lopende discussie is nu onderwerp van een rechtszaak tussen AutoDesk, de makers van AutoCAD, en ene meneer Vernor die tweedehands exemplaren van AutoCAD verkocht via eBay. Eergisteren liep er nog een aardige draad over bij Tweakers, en gisteren verscheen een tussenvonnis in kort geding dat zegt dat het mag.

Het doorverkopen van een legaal aangeschaft exemplaar van een auteursrechtelijk beschermd werk is legaal, zo staat letterlijk in de Amerikaanse auteurswet (17 USC 106). Natuurlijk mag je geen kopieën maken en die verkopen, dit recht is beperkt tot het ene legaal gekochte exemplaar. Softwareleveranciers stellen echter al jaren dat dit recht niet opgaat voor software: je koopt geen software zoals je een boek koopt, maar je sluit een gebruiksovereenkomst. En als je software niet koopt, heb je geen “legaal aangeschaft exemplaar” en dan valt er niets door te verkopen.

In principe mag dat. Niet elke transactie waarbij je in ruil voor geld iets in je bezit krijgt, is een koop. Je kunt iets huren, lenen of tijdelijk in gebruik nemen. En zeker voor software had de Amerikaanse wetgever ook voorzien dat dat moest kunnen, zo blijkt uit de wetsgeschiedenis en uit de schaarse jurisprudentie. Uit de al wat oudere zaak United States v. Wise concludeert de rechter dat het gaat om de vraag hoe lang de licentie geldig is. Als deze eeuwigdurend is, is het een koop. Moet je na een zekere periode de zaak teruggeven, of vervalt de licentie na zekere tijd, dan was het een gebruiksrecht.

Echter, daar staat een hele trits recentere uitspraken tegenover die zich baseren op de tekst van de licentie. Als daarin staat dat de transactie geen koop is, dan mag de transactie niet als koop gezien worden. De rechter gaf in dit vonnis (via Cadcamnet) toe dat hier een levensgroot conflict zat. Hij ging daarom af op de oudste jurisprudentie. Je moet wat, nietwaar. Zijn uitspraak zou hoe dan ook in tegenspraak zijn met een deel van de jurisprudentie, geeft hij zelf toe. De bedoeling is natuurlijk dat AutoCAD in hoger beroep gaat en zo de hogere rechters dwingt om de knoop eens door te hakken.

Via Slashdot.

Arnoud

Zijn EULA’s rechtsgeldig? Die vraag is altijd goed voor een flink debat wanneer er weer eens een EULA met rare bepalingen opduikt. “De rechtsgeldigheid van een EULA wordt door sommigen betwijfeld”, zo meldt bijvoorbeeld Wikipedia. Maar er is geen duidelijk “ja” of “nee” te geven op zo’n algemene uitspraak.

De term “EULA” staat voor “End-User License Agreement” en wordt gebruikt om softwarelicenties aan te duiden die een bedrijf aan een consument (eindgebruiker) geeft. Een licentie is een contract. Om dus te kijken of een EULA “rechtsgeldig” is, moet je deze langs de regels van het contractenrecht leggen. Daarbij zijn vier stappen te onderscheiden:

1. Totstandkoming van een overeenkomst
2. Terhandstelling van de EULA-voorwaarden
3. Vernietigbaarheid van de EULA-voorwaarden
4. Strijd met hoger recht

Totstandkoming van een overeenkomst
De eerste vraag bij elke overeenkomst is of er eigenlijk wel een overeenkomst is. Daarvoor is nodig dat de ene partij een aanbod doet dat de ander aanvaardt. Bij een EULA is het aanbod een gebruiksrecht voor de software. Wie software rechtmatig verkrijgt (koopt in de winkel of downloadt bij de fabrikant of een geautoriseerde verspreider), heeft echter strikt gesproken geen EULA nodig.

Praktisch punt is wel dat vrijwel alle software tijdens de installatieprocedure je verplicht de EULA te aanvaarden. Doe je dat niet, dan kan de installatie niet worden voltooid. Dat is op zich een geldige constructie. De leverancier is niet verplicht om je de keuze te geven tussen een EULA of het beperkte wettelijke gebruiksrecht.

Natuurlijk ben je vrij om de EULA vervolgens niet te aanvaarden. Je mag dan de software niet gebruiken, en dat is natuurlijk wel zuur als je voor de software betaald hebt. De winkel zal de software niet terugnemen, omdat de doos geopend is. En bij een betaalde download is het al helemaal praktisch onmogelijk om de software te retourneren. Daar wringt iets: de leverancier kan toch niet zomaar voorwaarden opleggen en het tegelijkertijd onmogelijk maken om die af te wijzen? Dat klopt, en om te kijken hoe dat uitpakt voor EULA’s, moeten we naar het recht van de algemene voorwaarden.

Terhandstelling van de EULA-voorwaarden
De voorwaarden uit de EULA zijn voor elke klant hetzelfde. Daarmee zijn ze juridisch aan te merken als algemene voorwaarden. De belangrijkste eis is dan dat ze voor of bij het sluiten van de overeenkomst ter hand gesteld zijn, en ook nog eens op de juiste manier.

Dat roept dus de vraag op wanneer de overeenkomst gesloten is. Bij een aankoop is goed te verdedigen dat je de overeenkomst sluit wanneer je het geld betaalt en de software verkrijgt (in een doos of als een download). In dat geval zijn de EULA-voorwaarden niet van toepassing, omdat ze pas na het sluiten van de overeenkomst worden getoond.

Sommige sites verplichten kopers dan ook om akkoord te gaan met de EULA voordat ze de software mogen downloaden. Bij verkoop van software in dozen kan de EULA dan in een heel klein lettertype worden afgedrukt op de achterkant van de doos. Dat mag, zolang het maar voor een redelijk mens leesbaar is. In die situaties is de EULA gewoon van toepassing.

Een EULA die pas na een betaalde download wordt getoond, of die pas te lezen is na het openen van de dichtgesealde doos, is dus niet tijdig ter hand gesteld. Tenzij je er vanuit gaat dat de EULA en de koopovereenkomst twee gescheiden overeenkomsten zijn.

Maar er is nog een tweede eis: de EULA moet op de juiste manier ter hand gesteld zijn. De hoofdregel is dat je een stuk papier moet krijgen waar de EULA op staat. Wanneer de EULA alleen op het beeldscherm in te zien is, is sprake van een overeenkomst langs elektronische weg. De wet zegt dan dat de EULA op een zodanige wijze moet worden getoond dat deze door de gebruiker kunnen worden opgeslagen en voor hem toegankelijk zijn ten behoeve van latere kennisneming. Met een PDF of Word-bestand in de zipfile is aan die eis voldaan.

Tekst in een venstertje voldoet in beginsel niet aan deze eis. Het kunnen opslaan en later inzien is een belangrijke eis bij elektronische overeenkomsten. Er is echter vaak geen manier om achteraf nog eens de EULA na te lezen (probeer het voor de grap eens te vinden bij uw gekochte software). Natuurlijk zou je zelf de tekst kunnen proberen op te slaan, bijvoorbeeld door de tekst via kopiëren en plakken in een Word-bestand te stoppen. Maar zo veel moeite doen is niet de bedoeling van dit wetsartikel. In sommige gevallen is het trouwens onmogelijk om tekst te kopiëren uit het EULA-venster.

Vernietigbaarheid van de EULA-voorwaarden
Omdat EULA’s algemene voorwaarden zijn, mogen ze niet onredelijk bezwarend zijn. Bij consumenten als eindgebruikers geldt er bovendien een zwarte en grijze lijst met ‘verboden’ bepalingen. Een EULA-bepaling die daarmee in strijd is, kan dus worden vernietigd. Denk hierbij bijvoorbeeld aan de uitsluiting van aansprakelijkheid of een beding dat een Californische arbiter de enige is die mag beslissen over een geschil.

EULA’s zijn vaak erg streng: de software mag maar op één PC worden geïnstalleerd, en niet worden gekopieerd laat staan verspreid. Maar “streng” is nog niet hetzelfde als “onredelijk bezwarend”. Je zult als gebruiker moeten bewijzen dat de leverancier deze eis redelijkerwijs niet mag opleggen, of dat hij in een concrete situatie niet werkbaar voor jou is. De zwarte en grijze lijst draaien voor een aantal situaties die bewijslast om.

Strijd met hoger recht
In contracten mag je veel met elkaar afspreken. Op sommige plekken heeft de wetgever een grens getrokken: dit zijn de wetsbepalingen van dwingend recht. Hiervan mag je niet in je EULA afwijken. Zo heeft de verkrijger van een stuk software het recht om daarvan een backup te maken, ongeacht wat in de overeenkomst staat. Maar zulke bepalingen zijn wel de uitzondering.

Naast zo’n keihard, specifiek verbod zijn er ook nog meer algemene normen waaraan je een EULA zou kunnen toetsen. Zo mogen contractsbepalingen niet in strijd zijn met de redelijkheid en billijkheid, en zou je zelfs kunnen betogen dat een bepaalde bepaling uit een EULA in strijd is met een grondrecht zoals privacy of vrije meningsuiting. Sommige EULA’s verbieden bijvoorbeeld het publiceren van resultaten van benchmarks van de software zonder toestemming van de maker.

Aantonen dat sprake is van een inbreuk op een grondrecht zal niet meevallen. Een EULA mag best beperkingen stellen aan grondrechten, zolang die beperkingen maar niet verder gaan dan noodzakelijk is voor het doel. Die benchmarkbepaling zou bijvoorbeeld best gerechtvaardigd kunnen zijn bij een testversie die bij een select publiek verspreid wordt.

Samenvattend: EULA’s zijn in beginsel een rechtsgeldige manier om gebruikers van software bepaalde voorwaarden op te leggen. Wel moet de gebruiker ze tijdig hebben kunnen inzien, en bij elektronische teksten ze ook hebben kunnen opslaan. Bepalingen uit een EULA zijn te vernietigen als ze onredelijk bezwarend zijn, of als de gebruiker kan aantonen dat ze botsen met een hoger recht. Maar dat zal eerder de uitzondering dan de regel zijn.

Arnoud
De foto van de CD uit de envelop is gemaakt door Wellington Grey en is beschikbaar onder de Creative Commons 3.0 BY-SA licentie.

De Belastingdienst overtreedt volgens een open source-deskundige meerdere open-sourcelicenties met de aangiftesoftware, meldt Webwereld. Softwareontwikkelaar en -auditor Peter Roozemaal heeft de Belastingaangiftesoftware voor Linux uitgeplozen. In zijn rapport meldt hij dat de OpenSSL en GTK+ licenties niet zijn nageleefd.

De OpenSSL licentie vereist namelijk dat je in de documentatie bij het product de licentievoorwaarden vermeldt. De Belastingdienst volstaat met een link naar de licentievoorwaarden zoals die op internet te vinden zijn. Slordig.

Voor GTK+ ligt het iets gecompliceerder. Deze bibliotheek is beschikbaar onder de LGPL versie 2. De Belastingdienst heeft de software statisch gelinkt met haar applicatie. De LGPL eist dan dat je de gebruiker in staat stelt de GTK+ onderdelen te vervangen. Wat je daarvoor precies moet uitleveren, hangt af van de situatie, maar omdat de Belastingdienst simpelweg niets heeft uitgeleverd, is het wel duidelijk dat de licentie op dit punt niet is nagekomen.

Pijnlijk. Maar wat is de consequentie? Roozemaal schrijft namelijk:

Zolang de Belastingdienst niet aan alle van toepassing zijnde licentievoorwaarden voldoet, is er sprake van auteursrechtinbreuk en verspreiding van de Aangifteprogramma’s behoort gestaakt te worden totdat aan alle licentievoorwaarden voldaan kan worden.

Niet helemaal.

De OpenSSL licentie bepaalt nergens dat de licentie automatisch vervalt als je hem schendt. Daarvoor zal dus een rechtshandeling van de makers nodig zijn. In Nederland zijn softwarelicenties contracten. Wie een bepaling uit een contract niet naleeft, schendt het contract. Op grond daarvan mag de licentiegever het contract ontbinden. Maar dat gaat niet automatisch.

De GTK+ licentie heeft wel een bepaling over ontbinding bij schending:

You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

Die laatste zin beperkt het effect tot wat de Belastingdienst zelf doet. De ontvangers/downloaders van de software mogen deze gewoon blijven gebruiken. Alleen verdere verspreiding van de software door de Belastingdienst of anderen is niet toegestaan.

En ik vraag me nog af in hoeverre toepassing van een dergelijke algemene voorwaarde niet als onredelijk bezwarend te zien is in situaties als deze. Naar Nederlands recht mag je een contract bij een tekortkoming niet ontbinden als “de tekortkoming, gezien haar bijzondere aard of geringe betekenis, deze ontbinding met haar gevolgen niet rechtvaardigt.” Dit is geen dwingend recht (zo te zien) maar of je zó ver kunt gaan in algemene voorwaarden, betwijfel ik.

Het is voor mij dus geen uitgemaakte zaak dat de Belastingdienst haar licentie op GTK+ kwijt is en de software niet meer mag verspreiden. Maar ze moeten wel als de wiedeweerga aan de slag om deze problemen te repareren. Want uitermate slordig is het wel.

Heeft iemand dit al aan het GTK+ team gemeld eigenlijk?

Arnoud

Een oud gezegde luidt: als je van je hobby je werk maakt, heb je geen hobby’s meer. En je bent ook nog het auteursrecht op je hobbywerk kwijt, zou ik daar aan willen toevoegen. Veel mensen denken, als je iets in privétijd maakt met je eigen materiaal, dan heeft je baas daar niets over te zeggen. Maar dat is niet waar.

In een recent vonnis (update 2/7: LJN BD5822) las ik over een werkgever (het ministerie van Binnenlandse Zaken) die werd verrast door een aantal copyright notices, aangebracht door een ontevreden werknemer in de uitvoer (HTML-pagina’s) van een aantal webapplicaties. Die werknemer was namelijk van mening dat de rechten op een deel van de applicatie bij hem lagen, omdat hij gebruik maakte van in eigen tijd ontwikkelde software en bovendien niet schriftelijk opgedragen was dergelijke software te maken. Hij gaf daarbij aan dat

het door hem vermelden van “copyright 2006 X” in de bronvermelding van bovengenoemde producten en het niet beschikbaar stellen van de broncode mede het gevolg is van het feit dat hij, ondanks veelvuldig aandringen, de werkzaamheden waarvan hij vindt dat ze niet binnen de functie vallen, niet als opgedragen taken schriftelijk bevestigd kan krijgen.

Met andere woorden, hij erkende zelf dat hij de opdracht had gekregen. En als je iets maakt in opdracht, ligt het auteursrecht bij je werkgever. Ook als het totaal niet tot je werkzaamheden behoort om het te maken. Je zou de opdracht kunnen weigeren omdat het niet tot je werk behoort, maar als je de opdracht aanvaardt, dan is het deel van je werk en dan liggen de rechten bij je werkgever. Je kunt niet een opdracht van je werkgever aanvaarden en dan auteursrecht op delen van het resultaat claimen.

Zoals de rechter het motiveert in het vonnis:

Het is innerlijk tegenstrijdig om enerzijds te erkennen dat hem (programmeer- en ontwikkel)taken zijn opgedragen als gespecificeerd in zijn eigen e-mail van 13 maart 2006, maar bij uitblijven van de verlangde schriftelijke bevestiging daarvan door zijn werkgever (…) opeens te stellen dat het geen opgedragen taken betrof. Alleen omdat hij meende dat deze taken zijn functie te buiten gingen, heeft hij in dit aldus escalerende arbeidsconflict naderhand opeens gesteld deze als niet langer opgedragen te beschouwen en is hij zich vervolgens op eigen auteursrechten van de applicaties gaan beroepen.

Artikel 7 van de Auteurswet zegt dat de werkgever het auteursrecht toekomt op alles wat je maakt dat past binnen je functieomschrijving. Of dat nu thuis is of op het werk, op je eigen PC of de laptop van de zaak is niet relevant. Wil je dat niet, dan moet je daar goede afspraken over maken met je werkgever.

Zie voor meer informatie mijn Spoedcursus auteursrecht: Eigendom van een beschermd werk.

Je kunt natuurlijk ook een hobby kiezen die niets met je werk te maken heeft.

Zijn jullie hier wel eens tegenaan gelopen? Of wat voor afspraken heb je met je werkgever over dingen die je maakt en die in de buurt komen van het werk?

Arnoud

Soms moet je mensen even porren om ze weer aan het bloggen te krijgen, en klaarblijkelijk is me dat bij Menno Weij gelukt.:) Hij reageerde gisteren op een opmerking in mijn blogpost over licenties en contracten waarin ik stelde dat wie software legaal downloadt, geen EULA hoeft te aanvaarden om deze te mogen gebruiken.

Menno zegt daarover:

Dit is naar mijn stellige overtuiging onjuist. Immers, je kunt er donder op zeggen dat de EULA overeenkomst bepaalt dat de software niet gebruikt mag worden indien men de EULA overeenkomst niet wenst te accepteren.

Ik geef toe dat mijn opmerking niet bepaald een mainstream uitleg van de Auteurswet is, maar deze redenering gaat me ook weer wat te snel. Als ik de EULA niet aanvaard, dan heb ik verder niets te maken met wat er in de EULA staat. Dus of daar nou staat dat ik de software niet mag gebruiken, is voor mij dan irrelevant. De auteursrechthebbende zal op grond van zijn auteursrecht tegen mij in actie komen, maar de inhoud van de EULA is daarbij volstrekt irrelevant.

Maar als ik de EULA niet aanvaard, mag ik de software dan gebruiken op grond van art. 45j? Menno vindt van niet:

Indien [de EULA niet aanvaard is], dan mag de software niet gebruikt althans gedownload worden. Immers, voor dat gebruik is alsdan geen toestemming verkregen van de auteursrechthebbende op die software. Je kunt dus ook niet teruggevallen op de wettelijke gebruiksrechten voor software in de Auteurswet, want je bent geen rechtsgeldig gebruiker.

Dat lijkt mij dan weer volstrekt onjuist. Het downloaden van software gebeurt voordat ik de EULA zelfs maar te zien krijg. Het is niet mogelijk om mijn downloadhandeling bij nader inzien alsnog te onderwerpen aan voorwaarden die ik pas na de download te horen krijg.

Natuurlijk zou de rechthebbende de EULA voorafgaande aan de download kunnen tonen, en zelfs expliciet een akkoordklik kunnen eisen voordat de download in gang gezet wordt. In dat geval is de download wel onderworpen aan de EULA. Maar dat is op internet de uitzondering en niet de regel.

Gebruikelijk is: je vindt een leuk stukje software, je downloadt het en dubbelklikt op het Installeren-icoon (hopelijk na een viruscontrole) en dan krijg je het bekende scherm met de EULA voor je neus. Of de EULA staat ergens in een tekstbestandje bij de andere programmabestanden.

Mijn stelling is dus dat ik in die gebruikelijke situatie (EULA na download pas aan mij getoond) een rechtmatig verkrijger in de zin van art. 45j Aw ben. Ik mag dan de software gebruiken binnen de grenzen van datzelfde art. 45j.

Spoor/Verkade/Visser lijken het hier op p. 597 met mij eens te zijn:

Rechtmatig verkrijger is iemand aan wie de rechthebbende of zijn (daartoe bevoegde) licentienemer het programma ter beschikking heeft gesteld. De wijze waarop dit is geschied doet niet ter zake: het kan zijn door verkoop, uitlenen of verhuur van een exemplaar, maar ook on-line.

Bovendien zegt dit artikel 45j “tenzij anders is overeengekomen”. Als een verkrijger pas rechtmatige verkrijger is nadat hij de EULA heeft aanvaard, zou deze bijzin geen betekenis meer hebben. Er moeten dus situaties zijn waarin men de licentieovereenkomst niet heeft aanvaard maar toch rechtmatige verkrijger is.

Arnoud
De foto van de CD uit de envelop is gemaakt door Wellington Grey en is beschikbaar onder de Creative Commons 3.0 BY-SA licentie.